導言

orchestrator 的設計目地：

速度

如何在保持高可用性的前提下提交功能。

擴展(軟體和團隊)

去耦合達到可擴展性。

抽象化基礎

基於容器開發而非環境，基礎環境就不再重要。

效率

應用程式自動分配在機器

而 k8s 勝出了。

架構

本書有第一版(2018年)和第二版(2020)年，兩版只有第一章緒論是相同的，其餘章節的內容都有一些訂正，相信不久還會再出第三版，又是很多內容的更動與修正。
為什麼會更動如此頻繁呢？ 可以看到開源庫： https://github.com/kubernetes/kubernetes 每天都還在修正與更動，可以說整個專案還相當的活躍。
如筆者所擷取的摘要，很多大公司或是利基點時別的小團隊？，有全球化部署的需求，想要靠一套系統去滿足世界各地種種的基礎環境，想想就不可思議了。

摘要

實作全球部署
現在全世界每一個區域都有自己的組態檔,衍生的問題變成你該如何更新不同區域的組 態權-使用多個區域最主要的目的是確保服務的高可靠度跟可用狀態。雖然說將問題架 構在雲端或資料中心的服務中斷上是很合理的,但事實上大多數的服務中斷都發生在新 版本的軟體發布之後。因此,服務高可靠度的關鍵在於限制「全面性」的變動。也就是 說,當你在不同區域發布新的版本時,最好是小心地在不同區域之間一個一個循序漸進 的釋出,以確保你有辦法在第一個區域發布之後進行驗證並增加信心,接著才往下一個 區域更新。
全球化的軟體更新相較於單一指令一次更新來說,比較像是一個工作流程。一開始你先 在測試環境上發布新版,並且更新到最新的版本,接著再慢慢更新到每一個區域。但是 你該如何組織這些不同的區域,而你又該花多少時間驗證每一個區域的部署呢?
部署一個區域換到下一個區域中間所需要等待的時間,取決於你的應用程式「平均發生 「問題」所需的時間,這個時間通常代表新版本的程式發布後,發現問題(如果有的話) 所需要的平均時間。很顯然地,發現每一個不同的問題需要不同長度的時間,所以你需 要了解平均所需要的時間。大規模的管理應用程式是機率性的問題,並沒有一個肯定 的答案,所以你可能想要等到應用程式出錯率降低到你覺得舒服才開始往下一個區域移 動。有時候你可以從應用程式平均出錯時間乘以兩到三倍當作一個起點,但一切還是取 決於你的應用程式本身。
要決定區域的更新順序之前,你需要先了解每一個區域特性。舉例來說,你可能會有高 流量的區域跟低流量的區域,根據應用程式的性質,也許有一些功能在某些地理區域特 別受歡迎,決定新版本發布的時程表時必須將這些特性納入考量。你應該會想要從流 量低的區域開始更新,這樣可以確保發生問題時可以控制受影響的範圍。這並不是絕對 的規則,有些早期的問題常常很嚴重,在你第一個區域更新之後立刻就會顯現出來,所 以,減少使用者受到的類似問題的影響比較合理。接著,你可以開始更新到高流量的區 域,一旦你成功的透過低流量的區域驗證新版的應用程式是正常的,你就可以開始測試 大規模流量的環境下是否會出現問題,要這麼做唯一的辦法是將應用程式發布到單一的 高流量區域。當你成功的讓應用程式在高低流量都經過驗證後,就可以肯定你的程式準 備好部署到世界各地了。不過,如果每個區域都有一些差異,你應該放慢部署的節奏, 確保不同地理區域都測試過,然後才大量部署。

總結

難易度

⭐⭐⭐⭐

自備技能

1.軟體操作經驗
2.Docker 經驗

適合對象

中階

心得

如 Docker 入門與實戰 第三部份所探討的內容，為了補足這部份的不足，就誕生了許多 orchestrator 編排器軟體。
到了 2018 年時，已成為了編排器 orchestrator 軟體大戰，那時百花齊放，但今時今日就是 k8s 戰贏了，其他曾經的曇花一現的過往，就放水流吧～ 要我提，我也想不起來。